Declarative techniques for model-driven business process integration

state machines, 14 and Pi-calculus 15 have been presented recently. The semantics are usually used to devise techniques to automatically verify properties of the activity diagrams. However, none of these formalizations is worked out in such detail that it can help in developing sound transformation, normalization, or refactoring algorithms that transform one arbitrary UML 2.0 activity diagram into another, equivalent representation. Similarly, formalizations of BPEL4WS have been developed based on communicating automata, 16 abstract state machines, 14 and Petri nets, 17 but scalable algorithms that allow a tool to automatically reason about a given BPEL4WS program are only in the initial state of development. 16,18 AUTOMATIC ANALYSIS OF CONTROL-FLOW MODELS The informal description of the ECCS example clearly distinguished several meaningful subprocesses, which interact with each other to implement the ECCS system. The control-flow model for this example is ‘‘flat’’ in the sense that it does not use structured activities to create a hierarchical model in which the various subprocesses can be easily identified. In order to improve the scalability and performance of model compilation techniques, it makes sense to complement them with analysis techniques that can identify such subprocesses instead of relying on the human designer to provide a well-structured hierarchical model. Today’s workflow code-generation tools lack such analysis capabilities and would map large, flat models to large, monolithic code. IBM SYSTEMS JOURNAL, VOL 44, NO 1, 2005 KOEHLER ET AL. 51 The close relation of control-flow models to controlflow graphs of programming languages enables the use of techniques from the fields of compiler optimization and program synthesis in addressing the model transformation problem. Control-flow analysis can reveal very interesting insights into a structure of a business process that can later be exploited to generate optimized workflow instructions. In the following, we discuss two main techniques: an automatic analysis to discover subprocesses in large, flat control-flow diagrams based on so-called two-terminal regions, and an automatic analysis of how to transform sequential flows containing unstructured cycles into compact workflow code based on the notion of reducibility from compiler theory. In the latter technique, flows with unstructured cycles that have a nonreducible control-flow graph are transformed into a state machine represented in BPEL4WS, while flows with unstructured cycles that have a reducible control-flow graph are normalized and encoded in BPEL4WS. Identification of subprocesses A closer look at Figure 2 shows that structural regions in the control-flow graph correspond to the ECCS subprocesses discussed previously. These regions are characterized by sets of nodes that have a single entry node to the region and a single exit node from the region. This structural characteristic seems to be quite common in control-flow models, and it can be exploited to identify regions in the process model that can be analyzed independently of each other. Flow-graph analysis of computer programs has defined so-called two-terminal regions, 19 which provide an appropriate definition of the structures in which we are interested. We next review some relevant concepts from compiler theory 20 that form the foundation for our analysis and transformation techniques. Definition 1. In a directed graph with one entry and one exit node, a node n is said to dominate (or predominate) a node m if every path from the start node to node m goes through node n. The dominance relation is transitive; that is, if a node n 1 dominates a node n 2 and n 2 in turn dominates another node n 3 , then n 1 also dominates n 3 . Definition 2. A node m postdominates a node n if every path from node n to the exit node goes through node m. If there is an edge from a node n to a node m in the graph, then n is called the predecessor of m, while m is called the successor of n. Definition 3. A two-terminal region is a subgraph where 1. a single entry node exists in the set that dominates all other nodes in the set, as well as all their predecessors, which must also be in the set, and 2. a single exit node exists in the set that postdominates all other nodes in the set as well as their successors, which must also be in the set. The two requirements in this definition ensure that (1) there is no path from the outside into the twoterminal region that does not pass through the entry node, and (2) there is no path from the two-terminal region to the outside that does not pass through the exit node. The notion of two-terminal regions can be used as a heuristic to discover subprocesses in large controlflow graphs. Applied to the ECCS example, the heuristic identifies the following regions: 1. A region R1 comprising the init (entry node), register, logon, and authenticate actions and the decision nodes D1, D2, D3, and D4 (the exit node). 2. A region R2 with entry node fork F1 and exit node join F4 to comprise the verify, select, configure, put, and order actions. 3. A nested region R3 inside region R2 with entry node select, exit node merge M, and the configure and put actions. After having identified these three possible regions in the ECCS, each of the regions can be analyzed separately. Regions R1 and R3 comprise unstructured cyclic flows, which are sequential. No parallelism can occur because of the restrictions we imposed on the control-flow semantics. Unstructured cycles have more than one entry or exit point into or out of the cycle. Region R2 is a concurrent region, in which the cyclic product-selection process synchronizes with the simple verification process, but the synchronization link lies outside the unstructured cycle. The cycle contains the select, configure, and put actions; whereas, the synchronization is established between the verify and order actions. KOEHLER ET AL. IBM SYSTEMS JOURNAL, VOL 44, NO 1, 2005 52 The structure of cycles and the types of synchronization (between cyclic or linear threads) have to be transformed into functionally equivalent BPEL4WS code. Functional equivalence establishes a desirable correctness criterion for our subsequent transformation. When provided with the same input data, the original control-flow model and the generated, functionally equivalent BPEL4WS model yield the same output. Functionally equivalent transformations of Turing-complete programs are always possible, 21 but may require the introduction of new guard variables and the duplication of code in the case of nonreducible flow graphs. In the worst case, the transformation may lead to an exponential expansion (or ‘‘blow-up’’) of the program. 20,22 Transforming the unstructured cyclic flows contained in regions R1 and R3 of the ECCS to BPEL4WS poses a particular problem, because the BPEL4WS language forbids unstructured cycles. Link elements in BPEL4WS define synchronization, and each link element has a source and a target activity. Control flow in BPEL4WS can be specified by using explicit BPEL4WS link elements or BPEL4WS structured activities such as sequence, switch, and while, the latter only allowing the designer to describe structured cycles. The while activity has a single exit, and it is exited when its defined termination condition is no longer valid. No unstructured control flow into or out of a while activity is permitted because link elements are not allowed to have their source activity within a while activity and their target activity outside, or vice versa. Furthermore, the control flow defined via link elements must be acyclic, that is, no cycles can be established via links. Unstructured cyclic flows can be transformed into well-formed BPEL4WS by adapting control-flow normalization techniques from compiler theory. 23,24 However, these techniques are currently limited to nonconcurrent cycles only. Fortunately, regions R1 and R3 are nonconcurrent and can therefore be transformed using these techniques. The concurrent region R2 is acyclic when we consider R3 as a single structured activity node. Furthermore, synchronization only takes place between sequential actions that are not part of any loop. Figure 3 outlines the structure of the BPEL4WS code which results from our analysis. The ECCS model can be considered as a typical example that falls into a limited, yet practically relevant class of concurrent processes, which seems to occur frequently in business process designs. In this class, each of the parallel flows may contain unstructured cycles, but any synchronization between the parallel flows only takes place between BPEL4WS activities lying outside of cycles. In the next subsection, we describe the basic principles underlying the transformation of regions R1 and R3 into functionally equivalent BPEL4WS code. Reducibility of identified regions As we briefly mentioned previously, the transformation of unstructured cycles may lead to an exponential expansion of the transformed program. This problem occurs in the case of nonreducible flow graphs. The notion of reducibility plays a major role in compiler theory. 20 In fact, many normalization and optimization techniques apply to reducible control-flow graphs only. Several techniques to determine the reducibility of control-flow graphs exist, one of the most established techniques being T1-T2 analysis. 4 In this technique, T1 and T2 are rules which stipulate the following: 20 Rule T1. If n is a node with a loop, that is, it has an edge which starts and ends at node n, delete that edge. Rule T2. If there is a node n (not the initial node) that has a unique predecessor m, then m may consume n by deleting n and making all successors of n (including, possibly, m) successors of m. After rules T1 and T2 have been applied (in any order), the limit-flow graph can be computed. The limit-flow graph remains when the rules T1 and T2 have been applied repeatedly until neither rule is applicable. If the limit-flow graph collapses into a single node, then the flow graph is reducible; Figure 3 Outline of the generated BPEL4WS code Flow starts Flow ends AND